SSM kernel: use p.clip for Q15 saturation, hoist B*s_x out of the m loop - #21

Two source-level optimisations to the SSM kernels, both bit-exact.

1. ssm_scan_q15: the Q15 clamp was written as two if-statements, which PULP GCC compiles to lui+addi+p.max+p.min (4 instructions) -- it does not pattern-match p.clip. Using __builtin_pulp_clip_r, as kernel_conv2d.c already does for INT8, emits a single p.clip. Hardware-loop body: 15 -> 12 instructions (3 multiplies unchanged), i.e. 4.00 -> 3.00 supporting instructions per MAC.

2. ssm_discretize_q15: B_q15[t*d_state+d] * s_x_q15 depends on (t,d) and a scalar -- neither depends on m -- yet it was recomputed d_inner (=1540) times per (t,d). Hoisting it to a per-t row turns the int64 4-way product into a 3-way one. Pure reassociation, so the result is unchanged; verified bit-exact over 5M random inputs. Hardware-loop body: 57 -> 33 instructions, 10 -> 6 multiplies.

Together: SSM inner-loop instructions per element 72 -> 45 (1.60x), which models to ~1.30x end-to-end on FEMBA-Tiny.

Note on SAT_Q15: it is only valid for int32 inputs. dB_temp in the discretize kernel is int64 and can exceed int32 range before clamping, so it keeps the explicit int64 comparison -- using p.clip there would narrow and wrap before the clamp.

Measured with riscv32-unknown-elf-gcc (GreenWaves gap_riscv_toolchain), -march=rv32imcxgap9 -mabi=ilp32 -O3.

Verification

• Reassociation checked over 5M random inputs — zero differences.
• Both kernels run end-to-end at FEMBA-Tiny dimensions
  (seq_len=80, d_inner=1540, d_state=16), original vs patched:
  0 mismatches across 1,971,200 dA/dB' elements and 123,200 y values.
• Re-verified under GVSOC on a pulp-open target (0 mismatches), where the two
  kernels together measured 1.20× faster. That run is memory-stalled (data in
  L2 rather than cluster L1), so it is a lower bound, not a GAP9 figure.

I could not measure on GAP9 itself: the public gap_sdk ships the GAP9 GVSOC
model sources but not the archi/chips/gap9_v2 register headers.